Summary

Fix a deadlock in llgo's unbuffered channel runtime where a receive that had already completed could keep waiting if another receive on the same channel overwrote the shared receive state before the first waiter woke up.

Root Cause

The runtime used channel-level getp state to determine whether an unbuffered receive rendezvous had completed. In a sequence like select { case <-ch: ... default: ... } followed immediately by another <-ch on the same channel, the later receive could set getp back to chanHasRecv, causing the earlier completed receive to wait forever.

Changes

• Add an unbuffered rendezvous sequence counter to runtime/internal/runtime.Chan.
• Increment the sequence when ChanSend or ChanTrySend completes an unbuffered rendezvous.
• Make ChanRecv and select receive completion checks use the captured sequence as well as getp.
• Add a language-level regression test under test/select_test.go that runs with both go test and llgo test.

Validation

• go test ./test -run '^TestSelectRecvCompletionNotOverwrittenByNextRecv$' -count=1
• timeout 30s ./llgo test ./test -run '^TestSelectRecvCompletionNotOverwrittenByNextRecv$' -count=1
• Verified the original etcd repro by rebuilding the etcdserver test binary with llgo and running TestPublishV3Retry; it now passes instead of hanging.